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MANAGEMENT OF DO-NOT -CALL DATABASES IN PREDICTIVE DIALING CALL CENTERS 



BACKGROUND 

5 The invention relates to generally to communications systems, and in particular, to 

systems that manage compliance with outgoing call regulations. 

Recent telephone solicitation laws and regulations mandate that a consumer, who 
expresses a desire not to be solicited by telephone, not be called. By regulation, a 
business must maintain a list of telephone numbers for such consumers, known as a "do- 
10 not-cair (DNC) list, and take appropriate measures to ensure that outgoing calls to 

telephone numbers on a DNC list are somehow blocked. The DNC lists can include a list 
specific to a particular business, as well as state- wide, national and industry-imposed lists. 
Thus, DNC compliance management is a particularly critical and challenging issue for 
businesses that rely on telephone solicitation as a core marketing tool. 

15 * SUMMARY 

In general, in ones aspect, the invention features a method of disseminating caller- 
related information in a do-not-call system that includes a plurality of predictive dialer 
systems each at a corresponding different one of a plurality of different locations, each of 
the plurality predictive dialer systems including an associated database system that is 

20 local to that predictive dialer system and that includes a do-not-call database. The 

method, which is implemented by a given one of the predictive dialer systems, includes 

receiving an update instruction that is of a first type or a second type, the first type 
being for blocking future calls to a specified telephone number and the second type being 
for removing a block on future calls to a specified telephone number associated; in 

25 response to receiving the local update instruction, concurrently sending first and second 
update notifications, wherein the first update notification is sent to the local database 
system and the second update notification is sent to another one of the plurality of 
predictive dialer systems that is located elsewhere from the given predictive dialer 
system; and in response to receiving the first notification at the database system 
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associated with the given predictive dialer system, updating the do-not-call database 
included therein, wherein the second update notification is for causing an update of the 
do-not-call database at the other one of the plurality of predictive dialer systems. 

Other embodiments include one or more of the following features. The method 
also includes, in response to receiving the local update instruction and before 
concutrently sending the first and second update notifications, verifying that a first token 
associated with the received update instruction requires that the other one of the 
predictive dialer systems be updated and wherein the second update notification includes 
a second token for indicating whether the other one of the predictive dialer systems needs 
to forward an update notification to yet another one of the predictive dialer systems. The 
first token is a count variable and the verifying involves decrementing the count variable 
and then confirming that the count variable is different from a predetermined value. The 
second token is the decremented value of the count variable. The method also includes, 
after receiving the update instruction and prior to sending the second update notification, 
retrieving from a configuration file that is local to the given predictive dialer system an 
address for the other predictive dialer system and wherein the sending of the second 
update notification is to the retrieved address. The method also includes either generating 
the update instruction locally to the given predictive dialer system or alternatively, 
received the update instruction from an entity that is remote from the given predictive 
dialer system. 

In general, in another aspect, the invention provides methods and apparatus for 
processing call information for calls to be placed by predictive dialers deployed at 
different geographic locations within a communications network. The methods include 

(i) receiving call information for a number to be called by one of the predictive dialers; 

(ii) processing the call information to determine if the number is on a Do-Not-Call (DNC) 
list, a copy of which is maintained in association with each of the predictive dialers; (iii) 
if the number is determined not to be on the DNC list, determining if the number is to be 
added to the DNC list; and (iv) enabling an update of the DNC list copy associated each 
of the predictive dialers with information that includes the number so that each of the 
predictive dialers has access to the information in near real-time. 
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Particular implementations of the invention may provide one or more of the 
following advantages. The DNC compliance management solution provides call centers 
with the ability to comply automatically with consumer DNC laws. The solution's DNC 
server application software "plugs-in" to supported predictive dialers, and provides the 
5 predictive dialers with real-time access to the do-not-call status of each phone number, 
thus allowing the predictive dialers to dial only non-restricted telephone numbers. The 
DNC compliance management solution also provides the ability for any client's 
telemarketing professional to, at the request of a consumer, instantly restrict a phone 
number by pressing keys on their telephone keypad. When this action occurs, that 
1 o telephone number is restricted for all other telemarketing professionals in the organization 
of that client, regardless of where they are located. State and federal updates to the DNC 
laws are updated nightly, and client-specific DNC requests are updated in real-time. 

Other features and advantages of the invention will be apparent from the 
following detailed description and from the claims. 

15 DESCRIPTION OF DRAWINGS 

FIG. 1 is a block diagram of a communications network that supports a *T>o-Not- 
Call" (DNC) compliance management infrastructure for predictive dialer call centers. 

FIG. 2 is a block diagram of an exemplary predictive dialer call center that 
includes a pair of DNC servers that couple to a DNC service network. 
20 FIG. 3 is a high-level diagram of the databases of the DNC management system 

(shown in FIG. 2). 

FIG. 4 is a block diagram of a communications network that supports DNC 
compliance management infrastructure that provides DNC service to multiple clients. 

FIG. 5 is a block diagram of a centralized DNC database that stores and manages 
25 DNC data for multiple clients, 

FIG. 6 is a block diagram of a network that supports a DNC management 
infrastructure for a client that uses both interactive voice response (IVR) systems as well 
as predictive dialer call centers. 

FIG. 7 is a block diagram of the Local Exchange Carrier (LEC) switch/TVR 
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network (shown in HG 6). 

FIG. 8 is a block diagram of the DNC service Point-of-Presence (POP) (shown in 
FIG. 6). 

FIG. 9 is a flow diagram of an exemplary DNC call processing for IVR systems. 
Like reference numerals will be used to represent like elements. 

DETAILED DESCRIPTION 

Referring to HG. 1, a communications network 10 includes a plurality of 
predictive dialer arrangements 12, 14, and 16 coupled to a Public Switched Telephone 
Network (PSTN) at respective PSTN access locations 18, 20 and 22. 

As is known in the relevant art, each predictive dialer in the predictive dialer 
arrangements is a system of outbound calling that dials without a caller (e.g., 
telemarketing agent) on the line. The predictive dialer dials a telephone number, listens 
and, when a live "hello" is detected, automatically transfers the call to an available agent. 
The predictive dialer typically places numerous calls simultaneously, checking each 
number for a live 4< hello" or for another call disposition. If the called number is busy, not 
answered or not working, the predictive dialer either discards or reschedules the call, then 
proceeds to dial another number. Predictive dialers cannot tolerate much delay, so the 
latency associated with any DNC call processing that is performed must be extremely 
low. Latency can be minimized by co-locating a client's predictive dialers and DNC call 
processing at given geographic locations, as shown in the figure. 

Each of these predictive dialer arrangements is connected to a Do-Not-Call (DNC) 
information gateway that connects to a private DNC service delivery network 24 used by 
a DNC service provider to provide a DNC service. The predictive dialer arrangements 
are deployed at different geographic locations within the network. The different 
geographic locations correspond to different geographic office locations of a client (or 
customer) of the DNC service provider. The predictive dialer arrangements can vary 
from client location to client location. For example, the predictive dialer arrangement 12 
can be single predictive dialer, the predictive dialer arrangement 14 can be a network of 
multi-site predictive dialers interconnected by a data network of the client, and the 
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predictive dialer arrangement 16 can be a network of multi-site predictive dialers 
interconnected by a network of the DNC service provider, as shown in the figure. 

The predictive dialer 12 is coupled to a first DNC information gateway 26a via a 
TCP/IP Local Area Network (LAN) 28a. The predictive dialer arrangement 14 is also 
5 connected to the first DNC information gateway 26a through the TCP/IP LAN 28a via a 
client data network connection 30. The predictive dialer arrangement 16 is connected to a 
second DNC information gateway 26b via a second TCP/IP LAN 28b. The DNC 
information gateways 26a and 26b are connected to the DNC service delivery network 24 
via Wide Area Network (WAN) connections 32a and 32b, respectively. 

1 o Also connected to the DNC service delivery network 24 is a DNC Administrative 

Center 34, which includes a networked redundant pair of central data management 
systems 36a and 36b. The central data management systems 36a, 36b include central 
databases for storing DNC list data. The systems 36a, 36b communicate with the DNC 
information gateways 26 over the DNC service delivery network 24 using TCP/IP 

15 connections 38a and 38b, respectively. The DNC Administrative Center 34 is responsible 
for reporting, billing, and keeping the DNC information gateways 26 up-to-date with the 
latest do-not-call data. The DNC Administrative Center 34 updates the gateways 26 on a 
nightly basis with any changes to state, federal or other applicable DNC lists that are not 
client-unique, as will be discussed in further detail later. 

20 The DNC service delivery network 24 and DNC Administrator 34 are operated by 

the DNC service provider. The predictive dialer DNC service is provided by 
functionality included in the DNC information gateways 26, the DNC service delivery 
network 24 and the DNC Administrative Center 34. 

Referring to FIG. 2, an exemplary predictive dialer call center 40 configured to 

25 utilize the DNC service is shown. The predictive dialer call center 40 includes one of the 
DNC information gateways, shown as gateway 26a, which includes two identical DNC 
servers 42a and 42b. The DNC servers 42 are coupled for redundancy, e.g. available for 
fail-over. The pair of DNC servers is connected to the DNC service delivery network 24 
and communicates with the DNC service delivery network over TCP/IP connections 44a 

30 and 44b for server 42a, and TCP/BP connection 44c for server 42b. The servers 42 are 
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coupled to a predictive dialer arrangement, shown as predictive dialer 12, as well. The 
DNC server 42a uses a TCP/IP connection 46a for communication exchanges with the 
predictive dialer 12. The redundant server 42b, in a fail-over capacity, uses a TCP/DP 
connection 46b for such communications. The predictive dialer 12 is coupled to a 
5 plurality of agent call systems, collectively agents 47, which are connected to the PSTN 
via at the access location 18 (PIG. 1). 

The predictive dialer 12 includes an API (DNCAPI) 48 that provides a DNC 
interface between the predictive dialer 12 and the DNC servers 42. The DNC servers 42 
can communicate with any predictive dialers equipped with the DNCAPI 48. The DNC 

10 servers 42 are responsible for processing DNC requests from predictive dialer 12, as well 
as other predictive dialers of the client, e.g., predictive dialers of arrangements 14 and 16 
(from FIG. 1). The DNC Administrative Center 34 communicates with the DNC servers 
42 over the network 24 (via connections 44a and 44c) to provide the DNC servers 42 with 
the latest updates to state and federal do-not-call lists, as discussed earlier. 

15 Thus, each client call center location in the network 10 (FIG. 1), as exemplified by 

the call center shown in FIG. 2, includes two co-located DNC servers 42, which 
communicate over a TCP/IP LAN with the call center's predictive dialer(s). Real-time 
DNC service is provided to client callers at the given location using dedicated on-location 
hardware and software. 

20 Examples of the type of hardware that is co-located at each client location include: 

two servers (for DNC servers 42a, 42b), e.g., Sun Netra-family servers or the like; one 
router, such as a Cisco 1600/1700/2600 family router; and a hub. In one configuration, 
the equipment requires two lOBaseT (or 100BaseT) LAN connections to the client's local 
area network. This connection must have reliable connectivity to the predictive dialer 

25 network(s). The TCP/IP configuration requires 3 IP addresses that are all routable to the 
predictive dialers. The DNC servers are dual Ethernet equipped. A primary interface 
attaches to the client LAN, and a secondary interface attaches to the hub (or equivalent) 
provided as part of DNC service provider's equipment 

The router would interconnect the DNC server to the secure DNC service delivery 

30 network 24. Two types of WAN connectivity to the DNC service delivery network are 
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supported: "dedicated frame-relay, e.g., 56K DDS or 128K FT1; and VPN/IPSEC tunnels. 
If VPN/IPSEC connectivity is chosen by the client, the DNC service provider will require 
an additional IP address that is Internet routabie and allows IPSBC tunneling protocols to 
pass through to DNC service provider's ISPs. 

5 All client DNC service transactions are handled locally by the DNC servers. The 

WAN connectivity is used by the DNC service provider to route urgent Do-Not-Call 
updates from the DNC Administrative Center 34 which can include other predictive dialer 
locations for the same customer or client. 

A system of software that resides on each DNC server 42 is referred to herein as 

1 o the Rapid Data Dispersal System (RDDS), indicated by reference numerals 50a and 50b 
for DNC servers 42a and 42b, respectively. The RDDS 50 is architected to ensure that 
changes to do-not-call data are quickly and efficiently transferred to all of a client 
organization's call centers so that no member of that organization violates a do-not-call 
law. Because of the high-speed nature of predictive dialers, it is essential that the DNC 

1 5 server respond almost instantaneously to predictive dialer queries while ensuring 
accuracy. The RDDS architecture is designed to meet this goal as well. 

Still referring to FIG. 2, and, in particular, the RDDS 50a for illustrative purposes, 
the RDDS 50a includes four software modules: a dialer interface module 54; a 
synchronization module 56; a data receive module 58; and a data update module 60. The 

20 RDDS further includes do-not-call databases 62. 

The dialer interface module 54 processes queries from predictive dialers, such as 
telephone number lookups, add requests, and delete requests. One instance of this dialer 
interface module exists for each connection to a predictive dialer. The dialer interface 
module 54 may read from the do-not-call databases 62, but does not write to them. When 

25 processing a telephone number lookup request, the dialer interface module 54 reads the 
do-not-call status from the databases 62 and returns this information to the predictive 
dialer. When processing a telephone number add or delete request, the dialer interface 
module 54 does not access the databases 62 at all. Instead, it adds the request to two 
queues - a database update queue 60a and a synchronization queue 56a. For security, the 

30 dialer interface module 54 validates the IP address for the source of the transaction. 
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The queues 56a and 60a used by the synchronization and database update modules 
are FIFOs (i.e., the data is processed in the same order in which it is received) with file 
system persistence, which means that if there were a power failure that caused a server to 
reboot, the queue and any data it contains would remain intact 
5 The format of the data in the two queues (the database update queue and the 

synchronization queue) is a text string of eight data elements, each separated by pipe 
symbols ( | ). These eight data elements, in order, are: 

1) Priority 
10 2) Hop Count 

3) OriginaLting IP Address (in hex format) 

4) Client key 

5) Database name 

6) Function code (l=check, 2=add, 3=delete) 
15 7) Phone number (must be 10 digits) 

8) Reserved 

An example queue record is as follows: 

i 

20 5|3|OA000005|lOOO|dma|2|7815551212|0 

The database update module 60 is responsible for adding telephone numbers to 
and deleting telephone numbers from DNC lists in the databases 62 of the DNC server on 
which it resides. Only one instance of this module may be running per DNC server to 
25 ensure that no more than one process writes to a database at a given time. The database 
update module 60 reads transactions from the database update queue, which is filled by 
the dialer interface module 54 and data receive module 58, and writes the changes 
directly to the appropriate databases. 

The synchronization module 56 handles the transfer of telephone number add and 
30 delete requests to other DNC servers in the network 10 for the same client For example, 
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if a client telemarketing organization has offices in Miami, Boston, and Seattle, and a 
telemarketing professional in Seattle adds a telephone number to the organization's DNC 
list, this information is transferred by the DNC server 42a in Seattle to both of the DNC 
servers 42a, 42b in Miami and Boston (via connection 44b), and as well as it's own 
5 redundant DNC server 42b in Seattle (via a TCP/IP connection 64). The synchronization 
module 56 reads transactions from the synchronization queue, which is filled by the dialer 
interface module 54 and the data receive module 58, determines which remote rnachine(s) 
the transaction must be transferred to, and does the transfer via TCP/IP to the data receive 
modules on the remote machines. 

1 o When the synchronization module 56 receives a transaction, it examines that 

. transaction for an indication of a certain number of "hops" of hop count. A hop count of 
each transaction, initialized for a value indicative of the total number of synchronization 
modules in the client's DNC set-up, is decremented by one each time it is received by a 
synchronization module. Once the hop count reaches a value of zero, the transaction 

15 record is prevented from being further transferred. This functionality ensures that a - 

transaction cannot "bounce around" infinitely between multiple synchronization modules. 

There is a configuration file 56b for each synchronization module 56. It contains 
the number of other call centers that exist within that company's network and the IP 
addresses of one of those other call centers (or alternatively the IP addresses of all of the 

20 other call centers). For each site for which it maintains IP addresses, it has the IP address 
for each of the two servers (the primary server and the secondary server). Thus, it gives 
the local call center that ability to use the secondary IP address if communication cannot 
be achieved with the primary IP address. That is, if the first server at the remote site is 
unreachable, the synchronization module will try to send its update to the secondary 

25 server. When the secondary server receives the update, it will in turn try to forward it to 
the primary server. 

The data receive module 58 receives telephone number add/delete transactions 
over TCP/IP connection 44a from remote synchronization modules, or from the DNC 
Administrative Center 34, and adds these transactions to the database update queue. 
30 How the RDDS works can be more clearly appreciated with a specific example. 
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As noted above, each synchronization module is responsible for updating a certain group 
of other synchronization modules, as defined in the configuration file on its local 
machine. Assume in this example that each synchronization module is responsible for 
notifying only one other remote system. In that case, when an add or delete occurs, the 
synchronization module establishes a hop count variable that is equal to that total number 
of call centers in the system, decrements that hop count variable, and then sends the 
notification of the change along with the decremented variable to the IP address of the 
other call center for which it is responsible (which information is contained in its 
configuration file). It also sends the update notification to a synchronization server in the 
DNC Administrative Center. That synchronization forwards the update to the IVR 
databases and other non-call center databases that need to be updated (see discussion 
below about IVR systems). 

When the notification is received at the other call center, the data receive module 
places it on the synchronization queue for the synchronization module and on the update 
queue for the update module. When the synchronization module gets to that notification, 
it decrements the hop count variable and checks to see if it is zero. If it is not zero, 
indicating that not all call centers have been notified of the update, it then sends the 
decremented hop count variable along with the notification to another call center as 
identified in its local configuration file. 

This process continues until the hop count reaches zero, indicating that all call 
centers have been notified. At that point, the synchronization module that holds the zero 
value hop count discards the notification and thus does not forward it to any other call 
centers. As should be apparent, the purpose of the hop count mechanism is to ensure that 
an endless loop of updates never occurs, where the same update gets passed back and 
forth between two or more synchronization modules. 

In the case that a synchronization module can not reach any primary or secondary 
servers at the next call center, it writes the update to a 'dequeue file" on its local machine, 
and sends out a message, which immediately notifies a technician that there is a network 
problem. The technician can then fix the problem and run a utility to re-add the failed 
updates to the synchronization queue to be reprocessed. 
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Though it was assumed in the example just given that a synchronization module 
was responsible for sending the received notification to only one other DNC gateway, it 
could instead be responsible for sending that notification to "n" other servers (where n is 
an integer greater than one), all of which are identified in the local configuration file. In 
5 that case, the hop count would be used in a similar manner to prevent and endless loop 
from occurring. 

The DNGAPI 48 is a C C library that provides real-time access to the DNC 
service. It provides a DNC interface to predictive dialers, thus allowing predictive dialer 
manufacturers to integrate the DNC service into their predictive dialers. The DNCAPI 48 

10 allows a predictive dialer application to: (i) open one or more connections to the DNC 
service; (ii) perform real-time lookups of telephone numbers to determine their DNC 
status; (iii) add phone numbers to the DNC databases 62; (iv) remove telephone numbers 
from the DNC databases 62; and (v) close connections to the DNC service. The DNCAPI 
48 can be implemented to support a variety of different operating systems, such as 

15 Windows NT, Solaris, linux, to name a few. 

Functions of the DNCAPI 48 include the following: 'DNC_connect' ; 
'DNC_disconnect'; 'DNCJnitialize'; 'DNC^unitialize'; 'DNCj-equest'. A description 
of each function follows. 

The DNC__connect function takes the form 'DWORD 

20 DNC__connect(DNCJEIANDLE *aHandle);' . The DNC_connect function establishes a 
TCP/IP connection to the DNC server 42a, and returns a valid DNC handle on success. 
The DNC handle may then be used in DNCjrequest function calls, for the purpose of 
checking the DNC status of telephone numbers. The connections are thread safe, that is, 
two or more threads are allowed to make simultaneous DNC queries using the same 

25 handle, but these requests will be queued and executed one at a time by the DNCAPI. 
The parameters include 'aHandle', which is a handle to the DNC connection (output 
parameters). The return values include the following: SUCCESS; 
DNCAPI3RROR^NOT_INrriAlJZED; DNCAPI_MAX_HANDLES_REACHED; 
DNCAPLERROR^CREATING^SEMAPHORE; SOCKET^INVALID JIOST; and 

30 SOCKET_CONNECT_ERROR. 
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By making multiple calls to this function, multiple connections to the do-not-call 
service may be established. In this case, multiple threads may make simultaneous calls to 
the DNC server, and they will not be queued by the DNCAPI. 

The DNCLdisconnect function takes the form 'DWORD 
5 DNC_disconnect(DNC_HANDLE aHandle);' . This function destroys the specified 

connection to the DNC server. The parameters include 'aHandle', which is the handle to 
the DNC connection to be destroyed. The return values include the following: 
SUCCESS; and DNCAPI O . 

The DNC ^initialize function takes the following form: 

10 

DWORD DNC_initialize( 
char *ip_addr, 
kit port, 

DNQJSTATUS default_dnc_response); 

15 

This function initializes the DNCAPI. It must be called before any other 
DNCAPI functions. The parameters include: 'ip_addr'; port and default_dnc_jesponse. 
The 'ip_addr' parameter specifies the IP address of the DNC service. The port parameter 
specifies the TCP/IP port number of the DNC service. The ip_addr and port information 

20 are provided to the calling application by the DNC service provider. The 

default_dnc_response parameter specifies the default status to be returned to the calling 
application in the event that there is an error in determining the DNC status of a telephone 
number. The return values include the following: SUCCESS; 
DNCAPLERROR^INTITALIZING; and 

25 DNCAPLERROR ^ALREADY^INITIALIZED. 

The DNCjrequest function is formatted as follows: 

DWORD DNC_request( 
DNC ^HANDLE aHandle, 
30 char *client_key, 
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char *campaign_key, 
char *user_key, 
DNC_FN fh_code, 
char *phonermm, 
5 int msjimeout, 

DNC_STATUS *response); 

This function makes a DNC request to the DNC server 42a. The parameters 
include the following: 'aHandle'; 'clientjcey'; , campaign_key , ; 'userjcey'; 'fc.code'; 

1 o 'phonenum' ; 'timeout' ; and 'response' . The 'aHandle' parameter specifies the handle to 
the connection to the do-not-call server. The *client_key' parameter specifies the ID 
of the client (user of the DNC service). The 'campaignjcey' parameter provides the ID 
of the telemarketing campaign, if used. The 'userjcey* provides the ID of the client 
caller making the call. The function code 'fn_code' parameter specifies the type of 

15 operation being performed. The valid function codes are: 'DNC_FN_CHECK\ which 
checks the telephone number for it's DNC status; 'DNCJFN_j\DD\ which adds the 
telephone number to the DNC database; and 'DNC_FN_REMOVE' , which serves to 
remove the telephone number from the DNC databases 62. The 'phonenum' parameter 
specifies the telephone number being checked. The 'timeout' parameter specifies a 

20 maximum amount of time (in ms) allowed for a query. The 'response' parameter 
specifies the response from the DNC server. 

For DNC_FN_CHECK, the valid responses are: 'DNC_STATUS_OK', 
indicating that a telephone number can be dialed; and 'DNC_STATUS JIESTRICTED', 
indicating that the telephone number is restricted and should not be dialed. The return 

25 values include the following: "SUCCESS; DNCAPLERROR w NOT_lMTIALIZED; 
DNCAPI_ERROR_TTMEOUT; SOCKET_RECV_ERROR; and 
SOCKET_WRITE_ERROR. 

The DNC_request function is a synchronous function. It will not return until the 
query has completed or an error occurs. The timeout parameter is provided to cause the 

30 function to return with the DNCAPI_ERROR_TIMEOUT error when the query takes 
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longer than the specified number of milliseconds. This function is also thread safe. Thus, 
two or more threads are allowed to make simultaneous calls to DNC_request using the 
same handle, but these requests will be queued and executed one at a time by the APL 

The DNC^uninitialize function is of the form 'DWORD DNC_uniiutializeO;'. 
5 It un-initializes the DNCAPI. The function accepts no parameters. The return value is 
'SUCCESS*. Once this function is called, the DNCAPI cannot be used again until it is 
re-initialized using the DNC_initialize function. 

The function 'errorjnsg' takes the following form: 

1 o char *error_msg( 

DWORD errnum); 

The parameter 'errnum' specifies an error code, typically, a code received from one of the 
DNCAPI functions. It returns an error message that is associated with the specified error 

15 code. On success, the return value is a pointer to a string containing the error message. 
On failure, the return value is an empty string. This function may be contained in a 
separate library. If so, the calling application must be linked to that library. 

Referring to FIG. 3, the databases 62 maintained on the servers 42 include two 
types of DNC databases: client-specific databases 70 and common databases 72. The 

20 client-specific databases 70 store DNC lists for a specific client such as a telemarketing 
organization. Usually this data comes from called parties (e.g., consumers) who indicate 
to a client caller (e.g., telemarketing professional) that they do not wish to receive any 
more calls from this client. The common databases 72 store lists which are imposed by 
governmental agencies, and which would apply to all client callers, regardless of 

25 organization, such as federal lists 74 and state lists 76. Other applicable common lists, 
indicated by reference numeral 78, may be included as well. 

FIG. 4 is a network architecture diagram of a network 80 that illustrates how the 
DNC compliance management infrastructure may be scaled for additional clients. A 
plurality of clients 82a, 82b,. . .82n, each having equipment deployed at various 

30 geographic locations, may be connected to the DNC service delivery network 24 through 
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at least one DNC information gateway, that is, a corresponding gateway 26a, 26b,.. .26n, 
respectively, which maintains common databases as well as databases unique to that 
client, as described earlier. 

FIG. 5 shows the internal organization of the Administrative Center's centralized 
5 data base, which stores client and common information for each client of the DNC 

service. DNC clients that are entered into the system for processing calls, either through 
dial-up voice IVR sessions, a predictive dialer or both, are assigned a unique client key 
that identifies that client to the DNC gateways and servers. Individual offices within a 
client are also assigned a unique office key when they are loaded, including the assigned 

1 o client key identifying the individual office to the DNC gateways and servers. 

Agents making prospecting calls on behalf of the client are assigned a pin number 
that requires it to be unique only within a single client A user key is then generated for 
that agent and is unique within the DNC server's centralized database across all clients. 
This client key, office key, and user key relationship, provide a great deal of flexibility 

15 within the system for reporting, agent and office relocations, and fail-over between IVR 
gateways. 

Fig. 5 shows the table organization of the data structure in which the do-not-call 
numbers are stored. The tables shown are as follows: 

tbl_Clients: a table of all clients using the system including relevant information 
20 about each client 

tbl_SystemUsers: a table of all individuals users of the system whether they be 
agents or system administrators 

tbLOfficeAgents: a table of all brokers. This table indicates among other things 
whether the agent is part of a team, whether he/she is active, and whether he/she is online. 
25 tbUActivelVRAgents: a table of all agents currently signed on through the IVRs. 

tbl_BlockedAgentStates: this table enables one to restrict certain agents from 
certain states identified in the table. 

tbLBlockedAreaCodes: this table enables one to restrict certain agents from 
certain area codes. 

30 tbl_ClientOffices: these tables are for the offices that are assigned to a given client 

15 



WO 03/107644 



PCT/US03/19145 



tbLCCenterDNCEntries: this table lists the numbers which are blocked for a 
given client / call center. 

tbLClientDNCCallEntries: this table contains the do-not-call numbers. 

tbLSunSystemNumbers: this table maps each ten digit number to a key of a 
smaller size. Using the number key instead of the ten-digit number reduces the amount of 
storage space that is required in the database to store the information. 

tbl_CallDetails: this table stores details about the calls that are mode for the 
purpose of generating reports. 

tbLCallCenterDNCQueue: this table stores the database changes that need to be 
sent out to the clients (e.g. predictive dialers) to update their local databases. The clients 
poll this table every five minutes to. retrieve what might be relevant to them. 

tbl_DMALIST: this table stores is the federal list of do-not-call numbers. 

tbLDNCSTATELIST: this table stores the state lists of do-not-call numbers. 

An important feature of this DNC service architecture is its ability to integrate 
predictive dialer applications with other telemarketing applications, such as a dial-up 
interactive voice response (IVR) based DNC application. As a result, if an organization 
has predictive dialer call centers in some locations, but also has telemarketing 
professionals in other locations using the dial-up IVR-based applications, telephone 
numbers restricted in one location are automatically restricted in the others regardless of 
the type of application being used. 

Thus, and referring to FIG. 6, in addition to the predictive dialer call centers, a 
network, indicated here as network 10', can include IVR applications that support DNC 
call processing as well. The DNC IVR application may be used by a client caller (e.g.. 
agent, telemarketer) working alone or as part of a call center. 

As shown in FIG. 6, the network 10' can be partitioned (as indicated by the 
dashed lines) into the following: an IVR access 90, in which multiple client offices 92 are 
coupled to an LEC (Local Exchange Carrier) network access point 94; LEC premises 96 
in which an LEC switch/TVR network 98 is co-located with a DNC Service Point-of- 
Presence (POP) 100; a predictive dialer call center 40 (as described earlier with reference 
to FIG. 2); and the DNC Administrative Center 34 of the DNC service provider. The 
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LEC premises 96, call center 40 and DNC Administrative Center 34 are each comnected 
to the DNC service delivery network 24, as shown. 

In this figure, further details of (he DNC Administrative Center 34 are shown. 
Each of the central data management systems 36 includes a network of one or more 

5 communication servers 102, one or more DNC servers 104 and a DNC database data 
center 106. The communications server(s) 102 act as a front-end to the system 36 and 
thus pass communications between the DNC service delivery network 24 and the back- 
end call processing DNC servers 104 and databases data center 106. 

Referring to FIG. 7, the LEC switch/IVR network 98 includes carrier switches 

10 110, which are coupled to the LEC Network Access 94 (FIG. 6), as well as an IVR 

system 111 via inbound (to the IVR system) PRI TVs circuits 112a and outbound (from 
the IVR system) PRI Tl' s circuits 1 12b. The IVR system includes a DNC IVR 
application 114. The IVR system 11 1 is connected to the DNC Service POP 100 (from 
FIG. 6) via an IVR data network provided by dedicated routers over a frame relay 

15 network for speed and reliabilityll6. 

Referring to FIG. 8, the DNC Service POP 100, which is coupled to an Ethernet 
segment in the LEC network 98 via another Ethernet segment 120, includes two DNC 
gateways 122a, 122b, which are coupled to the DNC service delivery network 24 an 
Ethernet LAN 124 and routers 126. Both routers are connected to the network 24 via a 

20 Tl/Fl Frame Relay ATM connection 128, with one router connected to the network 24 
using an ISDN dial backup connection 130. 

With respect to the interconnection of the IVR and the carrier's voice network, 
dedicated inbound voice circuits/trunks are required to support client access to the IVR 
application. These trunks terminate calls from client callers and provide the primary 

25 access to the IVR platforms running the DNC IVR application. The following 

characteristics are important to the IVR application. First, the inbound trunks must 
provide DNIS (dialed number) data to the IVR application with every incoming call, as 
the IVR application passes the DNIS to the DNC servers for identification of valid client 
offices and access credentials. Second, the inbound trunks should provide ANI when the 

30 ANI is available. The IVR application passes the ANI to the DNC servers for tracking 
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purposes. Lastly, the DNIS data is required to be predetermined number of digits, e.g. 10. 
Other characteristics of the inbound trunks are specified by the carrier and the IVR 
equipment supplier. 

It is possible to have multiple IVR applications located at carrier switch locations 
5 that have dense numbers of DNC client offices. In these cases, trunk groups may be 
configured by the carrier in such a way as to allow the use of all IVR inbound trunks 
across all IVR applications for any local access number provided by the carrier. This 
configuration provides the maximum load sharing and redundancy possible within the 
IVR cluster. 

1 o The DNC IVR application 114 requires dedicated outbound voice circuits/trunks 

to allow client callers to place outgoing prospect calls as part of the DNC service. The 
outbound trunks must allow a consistent 10 digit dialing operation for all calls (local and 
long distance). The TVR application 1 14 may add 1+ if necessary for the carrier's dialing 
plan. The outbound trunks allow the IVR application 1 14 to specify the ANI used on the 

15 outgoing call to support not only carrier billing requirements (on a station basis) but also 
possible future requirements forcing telemarketers to provide Caller ID information on 
prospecting calls. It is expected that DNC clients will spend the majority of their time 
bridged to outgoing calls, therefore the outgoing trunks should provide equal capacity as 
the incoming trunks allowing all active clients to have outgoing calls in progress 

20 simultaneously. All characteristics of the outbound trunks are the responsibility of the 

carrier and the IVR vendor equipment specifications. It is assumed that the carrier owns 
and operates the switches, the trunks between the switch and IVR, and all of the IVRs. 

Referring to FIGS. 7 and 8, the DNC IVR application 1 14 is a custom program 
that runs in the IVR system 111. Its primary purpose is to provide a telephonic front end 

25 to the DNC service. The DNC IVR application 1 14 terminates inbound calls from a DNC 
client caller for access to the DNC service. It interacts with the client caller over the 
inbound call using DTMF input to voice responses. It communicates over an IP network 
to the DNC servers 122 to validate client/caller credentials and verify DNC status of 
telephone numbers. It then establishes outgoing calls to prospects of the client if the 

30 DNC status of the telephone number permits. The DNC IVR application 1 14 allows the 
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client caller to enter final disposition status of calls via DTMF codes (including the 
addition of telephone numbers to the DNC database 106). Telemarketing agents typically 
access the IVR application 1 14 via local calls or 800 calls. The inbound call to the IVR 
system remains connected during the entire DNC session. The client caller may place 

5 multiple calls per IVR session. 

An overview of an IVR session is as follows. An agent (DNC service client) dials 
a local access number specific to his/her office (e.g., Acme Widgets, Atlanta GA). The 
IVR system 111 receives the incoming call and verifies that the DNIS (dialed number) is 
configured and "online" in the DNC database 106 using a special link protocol (over an 

10 IP network), as will be described. The DNC Admin Center 36 supports the functionality 
of allowing multiple clients or client offices to use or share the same DNIS number. This 
functionality is required for VOIP based carrier networks that use IP as the transport for 
voice data. In VOIP networks, the number of IP gateways allowing access to the network 
is limited, therefore clients and customers share these limited gateway resources to the 

1 5 network. The IVR system 1 1 1 sends the DNIS number to the DNC Admin Center 36, 
which checks if its DNIS number is valid and shared. If the DNIS is approved by the 
DNC database, one of two events based on the result occurs for the calling agent. If the 
DNIS number is determined to be a shared number, the agent is prompted to enter their 
Office Code 146b (via DTMF keys). The Office Code is verified using link protocol back 

20 to the DNC Admin Center. If the Office Code is valid or the DNIS number is not a 

shared number, the agent is prompted to enter the agent* s PIN code 146 (via DTMF keys) 
verified using link protocol. If the PIN code is valid, the agent is then prompted to enter 
destination telephone numbers to be dialed for prospecting purposes. Before placing the 
outbound call, the IVR application 114 again uses link protocol to verify that the 

25 requested telephone number is permitted (e.g., verify that it is not on state, Federal or 

client DNC lists, verify time zone parameters, verify agent/area code permissions, and so 
forth). If the Administrative Center 34 approves the destination telephone number, the 
IVR application 114 places an outgoing call to that number and bridges the agent's 
inbound call to the outbound call. . At the end of the call, the agent is prompted to enter a 

30 final status code (##, #0-9) for the call. 
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Once the final status in entered, the IVR application again uses the link protocol to 
send summary information to the DNC database 106. If the final status was entered as 
"#0", the last dialed number will be automatically added to the agent's client DNC list. 
The agent is then prompted to enter the next telephone number. Once the agent has 
completed making a series of outbound calls, he/she hangs up, thereby disconnecting the 
inbound call to the IVR application 1 14. 

The IVR application 1 14 uses the link protocol (interface) to the DNC database 
data center 106 to verify credentials and dialed numbers. In the embodiment described 
thus far, no outbound calls can be placed without positive acknowledgement from the 
DNC database data center 106, that is, the IVR application 114 makes no DNC or 
credential decisions locally. 

As part of the DNC administrative center, there is a server that is responsible for 
maintaining synchronization between the different DNC applications (the IVR and call 
center applications). This "synchronization server" accepts socket connections from each 
application, receives DNC add and remove transactions, and distributes them to the other 
applications, using the same rapid data dispersal (RDDS) technology which is used on the 
call center servers. This ensures that the do-not-call information used by both 
applications is consistent. There are three types of data that are transferred via this 
method: 

1) From the IVR application - When a phone number is added to a client-specific 
DNC list through the IVR application, the information is forwarded over a 
socket connection to the synchronization server, which in turn forwards the 
information to any call center servers that maintain the list for this specific 
client. 

2) From the call center application - When a phone number is added or removed 
from a client-specific DNC list through the call center application, the DNC 
server at that call center which processed the transaction will forward it to the 
synchronization server, which, through an ODBC connection, will forward the 
transaction to the IVR application's DNC servers. 

3) Non-client-specific adds and deletes (such as state and DMA lists), are sent 
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from the IVR application's DNC servers to the synchronization server, which 
forwards them to each of the call center servers. 

The synchronization server knows which DNC databases are being maintained by 
each of the DNC servers, so when it receives an add or delete transaction, it only forwards 
it to the specific machines which need to be informed. 

If the synchronization server has a problem communicating with any of me DNC 
servers, and is therefore unable to forward a transaction to a certain machine, it will add 
the transaction to a file, notify a networking professional at the DNC service provider's 
company of the network problem, and mark the transaction to be retried later. 

For the IVR application 114 to receive the DNC service, it must be able to 
commnnicate with at least 1 one of these servers at all times. The IVR application 1 14 
may be configured to load balance across all available servers. 

The DNC IVR link protocol allows the DNC IVR application 1 14 to communicate 
with multiple DNC service gateway servers 122, for example, two, as shown, that are 
placed at carrier-provided collocation facilities. It is a TCP session layer application 
between IVR systems 1 1 1 running the IVR application front-end 1 14 and the DNC 
servers 122 on the same IP network. Each of the functions of the IVR application 1 14 
includes a specific link protocol message that provides a standard way for the IVR 
application to transmit relevant information to and receive result codes from the DNC 
service. 

The link protocol has a total of 5 possible transaction or message types: 
transaction code 1, corresponding to a 'Verify DNIS' message; transaction code 2, 
corresponding to a 'Verify PIN' message or 'Verify Office Code and Pin' for VOIP based 
networks; transaction code 3, corresponding to a 'Verify Number to be Called* message; 
transaction code 4, corresponding to a 'Report call summary data and Final Status' 
message; and transaction code 5, corresponding to a 'Provide Manual Add to DNC list' 
message. 

In one embodiment, all messages or transactions from the rVR application 1 14 to 
the DNC gateway servers 122, include 13 fields of variable length separated by the Unix 
pipe "|" symbol. All data is character string, and no binary data passed. All transactions 
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end with a "|" symbol to ensure that multiple requests stored together can be parsed 
easily. 

It is assumed that each client caller has a specific DNIS number that terminates on 
the IVR system. The transaction code (transcode) 1 is a check of that DNIS number 
against the database in the central data center to see if the client caller is currently valid or 
is possibly a Call Center. Transaction code 1, which uses fields 1-6, has the following 
format: Transcode | UniquelD | Current Time-Date | Port# | lODigit DNIS | lODigit 
ANT. For example, an actual transaction code 1 message might appear as 
'l|CC34Z43H9NN|12:35:44-07042000|001|6035242214|6175551212||||||r. The DNC 
gateway servers 122 returns a message of the form 'UiuquelD [Return 
Code|OutboundANI/BTN* , where the Return Code is one of the following: ' 1" for 'DNIS 
/ Customer OK'; «2' for 'Not OK (Not Valid)'; '3' for 'This is a Call Center (do not 
prompt for PIN, using ANI validation)*; and '16' for 'Signal to IVR to Switch to Next 
Server*. 

Transaction code 2 is a validity check of the client caller's PIN number and Office 
number, if VOIP based network, against the database of the DNC database data center 
106. This code uses seven of the 13 fields and it formed as 'Transcode | UniquelD | 
Current Time-Date | In Port# | lODigit DNIS | lODigit ANI | PIN Number | Office Code'. 
In response to this code, the DNC gateway servers 122 returns the UniquelD and a return 
code from among the following: ' 1' for 'Pin Number OK' ; '2' for Tin Invalid (reason 
x)'; '3' for 'Pin Invalid' (reason y); '4' for 'Pin Invalid (reason z)'; and '16' for 'Signal 
to rVR to Switch to Next Server'. 

Transaction code 3 is the formal "do-not-call" processing on a destination number 
entered by a client caller. The DNC database data center 106 can either allow the 
number, or disapprove the numbeffor various reasons. The transaction code 3 specifies 
useful information in 8 of the 13 fields, in the format 'Transcode | UniquelD | Current 
Time-Date| In Port* | lODigit DNIS | lODigit ANI | PIN Number | Destination Number' . 
The DNC gateway servers 122, in response, returns the UniquelD and a return code from 
among the following options: 
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1 


Destination Number OK 


2 


Number Marked as "Do Not Call" 


3 


Number in Restricted to the Agent for Calling 


4 


Number currently in a "Time of Day" limitation 


5 


Reserved for future use 


6 


Reserved for future use 


7 


Possible Pin Fraud 


16 


Signal to IVR to Switch to Next Server 



The transaction code 4 passes all pertinent data to the database of the DNC 
database data center after an outbound call is completed. The transaction code 4, which 
uses all of the available fields, is formatted as follows: 

Transcode | ApexUniquelD | |Current Time-Date | In Port* | lODigit DNIS | 
lODigit ANI | PIN Number | Destination Number | Inbound Call Duration | 
Outbound Call Duration | Out Port# | CPA code | Final Status code 

Example: 

4|CC34Z43H9NN|12:35:4407042000|001|6035242214|6175551212|754983|21287 
39977|3644|240|121|0|0| 

The Final Status code can be any of the following: 

Call complete, no "appointment set", no DNC add 
Call complete, no "appointment set", add called number to DNC 

Call complete, "appointment set", no DNC add 
Call complete, "appointment set", no DNC add 
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The DNC gateway servers 122, in response to the transaction code 4, returns the 
UniquelD provided in the transaction code 4 message and a return code indicating that the 
data received is 'OK', that is, is properly received and processed (code T) or signaling to 
the IVR application to switch to another available DNC server (code '16'), e.g. in the 
event that the current DNC server has failed. 

Transaction code 5 is used to add a number as a DNC to the database manually, 
that is, not as part of the process of placing an outgoing call. The transaction code 5 
provides useful information in fields 1-8. It has the format 'Transcode | UniquelD | 
Current Time-Date| In Port# | lODigit DNIS | lODigit ANI | PIN Number | Destination 
Number'. The DNC server, in response to this code, returns the UniquelD and a return 
code, either '1' to indicated that the database was properly updated, '16' to signal to the 
IVR application to roll over to the another DNC server, 'IT to indicate that the database 
is off-line (assumes transaction is "good" and so is treated as a T) or '18' to indicate that 
the database is off-line and that the IVR application should play a "Call Technical 
Service" message. 

Referring to FIG. 9, a detailed operational flow of the DNC IVR application 114 
is shown. When the IVR application receives an incoming call from a DNC client caller 
(step 140), it received and attempts to validate the number the DNIS (dialed number) 
(step 142). To validate the number, the IVR application passes the DNIS to the DNC 
server using the link transaction code 1 (Transl). The interface between the IVR 
application 114 and the DNC gateway servers 122 (and therefore the Admimstrative 
Center 34) for this and subsequent link transaction codes is represented in the figure by 
link protocol 143 (indicated in dashed lines). The DNIS identifies offices on a per client 
basis in a "non-VoIP" network configuration. That is to say, all agents from the same 
office of a particular client dial the same DNIS to access the DNC IVR application and, 
therefore, the DNIS is only valid for one office of one client In a VOIP based network 
Fig 10, clients, as-well-as offices with the same client share the same DNIS number for 
access into the network. Information transmitted to the DNC gateway servers 122 in the 
transaction code includes the DNIS (as provided by the carrier's inbound trunk 
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configuration) and the ANI of the inbound call to the IVR (if available). The receipt of 
the "Transl" transaction by the DNC gateway servers 122 causes the DNC server to 
communicate with the Administrative Center 34 via the DNC service delivery network 24 
to verify that the DNIS is a valid and a provisioned client or clients for VoIP DNIS. The 
carrier typically provides large blocks of numbers pointing to the IVR system's trunks. If 
the DNIS cannot be validated (step 142), that is, a failure message is returned by the DNC 
gateway servers 122, the IVR application 114 instructs the client caller to verify the 
number with the DNS service provider (step 144). If, at step 142, the DNIS is validated 
for the incoming call and the IVR application determines that the client caller is not a call 
center and the DNIS number is not sharaed, the IVR application 1 14 provides a voice 
prompt asking the client caller to enter his/her Personal Identification Number (PIN) and 
attempts to validate the PIN received from the client caller (step 146). The client caller 
enters the PIN code using DTMF keys, and presses the '#' key. (The.'#' key is used at 
this prompt as a speed key, if the user waits after pressing the last digit, the IVR 
Application will timeout and use the digits collected so far as a PIN entry to validate). To 
validate die PIN, the IVR application 114 prepares another link transaction code, the 
transaction code 2 ('Trans2"), and forwards the transaction code to the DNC gateway 
servers 122. Key data values provided to the DNC gateway servers 122 in the transaction 
corresponding the transaction code 2 include the PIN provided by the client caller, the 
Office Code if prompted for, along with the DNIS and ANI (if available) of the inbound 
call. 

Since the DNIS of the inbound call is unique to a particular DNC client office in a 
non-VoIP network, me DNC Administrative Center 34 uses it in conjunction with the PIN 
entered by the client caller to validate whether the client caller has provided the correct 
credentials to access the IVR application. The Pin Numbers are unique within a DNC 
client, and only valid for a particular client office. The DNC client PIN codes are 
established by authorized DNC administrators of the client via a web site of the DNC 
service provider. If the DNC gateway servers 122 returns a response indicating that the 
PIN entered by the client caller is invalid, the IVR application allows the client caller 
several more attempts to enter a correct PIN and subsequentiy disconnects from the 
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inbound call if the PIN cannot be validated after the allowable number of retries (step 
148). 

If the IVR application receives from the DNC gateway servers 122 a response indicating 
that the entered PIN entered is valid, the IVR application 1 14 provides to the client caller 
-a destination telephone number (the number the client caller wishes to call) request voice 
prompt, to which the client caller responds by either providing the destination telephone 
number (using DTMF keys to enter the destination telephone number and # key to 
indicate completion) or pressing * *#0" to enter a 'Manual Add" sub-function) (step 150), 

When the IVR application receives the destination telephone number, it prepares a 
link protocol transaction code 3 (Trans3), and then passes this code to the DNC gateway 
servers 122. The transaction code 3 provides the DNC server with the DNIS and ANI (if 
available), PIN, the collected digits of the destination telephone number and the 
channel/card/circuit information (as available) for fraud prevention. In response to this 
code, the DNC gateway servers 122 checks the request destination telephone number for 
any restrictions, e.g., checking the number against DNC lists, such as state DNC lists, 
federal DNC lists, client DNC lists, as well as any time of day restrictions and agent/area 
code restrictions, and provides the results of the checking to the IVR application. The 
results indicate either that the request number can be dialled, or that the request number is 
somehow restricted and should not be dialled. 

Based upon the results of the link transaction associated with the transaction code 
3, the IVR application 1 14 either allows the call to proceed (and places the outbound call 
via a bridge to the inbound call)(step 152) or plays a message to the client caller stating a 
reason why the call will be blocked (step 154). If the call is dialled, the IVR application 
1 14 starts a timer to time the duration of the bridged outgoing call (step 156). 

If the outgoing call is placed, the client caller listens to call progress, speaks with 
the called party if the called party answers, possibly leaves a message on the answering 
machine of the called party or hears an IVR generated status if the call does not go 
through for network reasons. 

At the end of a successful call (including a ring with no answer), the IVR 
application prompts the client caller for a final status (step 158). Calls such as SIT tones, 
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busy, etc., also return the caller to this final status. The prompt may include a call 
progress indicating that that call was not answered. This final status must be entered 
before the client caller can be prompted to dial the next telephone number (by returning to 
step 150). Once the final status is entered by the client caller, the IVR application 1 14 
uses the link transaction code 4 (Trans4) to send request as well as summary data to the 
DNC gateway servers 122 for delivery to the DNC Administration Center 34, which can 
use the summary data information for client reporting purposes. 

When the final status code in the transaction code 4 indicates that the client 
entered a *W indicating that the called party asked to be placed on the client's "do-not- 
call" list, the Administrative Center 34 automatically adds the telephone number to the 
database of the DNC database data center 106. 

Once a telephone number is added by a client caller via the DNC IVR application, 
it cannot be reversed or removed except by an client authorized administrator using the 
DNS service provider's web site. 

The "appointment set" final status codes can be used at the discretion of the DNC 
client for internal reporting purposes. The use of those codes sets an "appointment" flag 
in the DNC call detail records. This client-defined purpose is available to DNC clients 
via the DNC service provider's web site. 

The IVR application terminates the outgoing call immediately when the first # key 
is pressed during the bridged outgoing call. 

If the call is blocked, the IVR application 1 14 again prompts the client caller to 
enter a destination telephone number to be called by returning to step 150, The IVR 
application 1 14 repeats step 150 until the IVR application 1 14 detects that the client caller 
has terminated the IVR session (by hanging up) (step 160). 

As mentioned earlier, the client caller may, at any time during the IVR application 
prompt to enter the destination telephone number (at step 150), enter ' W to be taken to a 
sub-function called 'Manual Add'. The 'Manual Add 1 allows the client caller to simply 
enter a 10 digit telephone number and request that it be placed on the DNC list without 
actually making an outgoing call. When the client caller enters the "#0" submenu 
function at the destination telephone number prompt, the IVR application 1 14 prompts 
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the client caller for a 10 digit telephone number and performs a manual add for the 
number entered by the client caller (step 162). The IVR application 1 14 performs the 
manual add function by composing a link transaction code 5 (TransS) and sending that 
code to the DNC gateway servers 122 for processing by the DNC Administrative Center 
34. 

The DNC client caller is only prompted once to enter a Manual Add telephone 
number. The next prompt is the main destination telephone number prompt. If more than 
one telephone number needs to be manually added, the client caller needs to invoke the 
manual add sub-menu each time with the "#0" code at the main destination telephone 
number prompt (step 150). 

Inbound calls to the IVR system activate the DNC IVR application for all DNIS 
assigned to the DNC service provider. In other words, as long as the IVR application 
plays any message upon receipt of an inbound call (such as "Please enter your PIN" or "A 
technical error has occurred" or "Please verify the number you are dialing", etc.), then the 
earner's IVR configuration is working for inbound calls. Properly formatted destination 
telephone numbers cause calls to be placed on the outbound trunks at all times. As long 
as the DNC IVR application is presenting 10 digit (or 1+10 depending on carrier 
configurations) numbers for outbound calls, the call is attempted by the carrier's switch. 

Note that do-not-call updates can originate from the following three different 
sources, namely, a telemarketing professional using a predictive dialer; a telemarketing 
professional using an IVR application; and the DNC Administrative Center. 

In the predictive dialer case, the update first appears in one of the DNC servers 
located at the customer site. The configuration file for the synchronization module is 
configured to send the update to another co-located server box at the customer site, and to 
the synchronization server machine in the DNC Administrative Center. The 
synchronization server at the DNC Administrative Center has the unique ability to then 
forward the update to the IVR application databases and to other predictive dialer 
configurations (n-1) for the same client at other geographic locations. 

In the case of the IVR applications, the IVR application automatically sends all 
updates to the synchronization server located in the DNC Administrative Center. That 
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server, 



r, based on the client id, then forwards the updates to one of the DNC servers at each 
of the appropriate customer site(s) that employs predictive dialers. Once the DNC server 
at each customer predictive dialer site receives the update, it forwards the update to its 
fellow / co-located DNC servers at that site. 
5 In the case of the DNC Administrative Center, when new state or dma database 

changes are made at the Administrative Center, these changes are forwarded to the 
synchronization server, which in turn forwards them to one of the DNC servers at each 
customer site. Once the DNC server at each customer site receives the update, it forwards 
the update to its fellow DNC servers at that site. 
10 Other embodiments are within the scope of the following claims. 

What is claimed is: 
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1 . A method of disseminating caller-related information in a do-not-call system that 
includes a plurality of predictive dialer systems each at a corresponding different one of a 
plurality of different locations, each of said plurality predictive dialer systems including an 
associated database system that is local to that predictive dialer system and that includes a 
do-not-call database, said method implemented by a given one of the predictive dialer 
systems and comprising: 

receiving an update instruction, said update instruction being a first type or a second 
type, said first type for blocking future calls to a specified telephone number and said second 
type for removing a block on future calls to a specified telephone number associated; 

in response to receiving said local update instruction, concurrently sending a first 
update notification and a second update notification, wherein said first update notification is 
sent to the local database system and said second update notification is sent to another one of 
said plurality of predictive dialer systems that is located elsewhere from said given one of the 
predictive dialer systems; and 

in response to receiving said first notification at said database system associated with 
said given one of the predictive dialer systems, updating the do-not-call database included 
therein, wherein the second update notification is for causing an update of the do-not-call 
database at said another one of said plurality of predictive dialer systems. 

2. The method of claim 1 further comprising, in response to receiving said local 
update instruction and before concurrently sending said first and second update notifications, 
verifying that a first token associated with the received update instruction requires that said 
another one of said predictive dialer systems be updated and wherein the second update 
notification includes a second token for indicating whether said another one of said 
predictive dialer systems needs to forward an update notification to yet another one of said 
predictive dialer systems. 
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3. The method of claim 2 wherein the first token is a count variable and wherein the 
verifying involves decrementing the count variable and then confirming that the count 
variable is different from a predetermined value. The synchronization server is responsible 
for managing this process through a call center queue with the DNC Administrative Center 
34. 

4. The method of claim 3 wherein the second token is the decremented value of the 
count variable. 

5. The method of claim 1 further comprising, after receiving said update instruction 
and prior to sending the second update notification, retrieving from a configuration file that is 
local to said given one of the predictive dialer systems an address for said another one of said 
predictive dialer systems and wherein the sending of the second update notification is to the 
retrieved address. 

6. The method of claim 1 further comprising generating said update instruction 
locally to said given one of the predictive dialer systems. 

7. The method of claim 1 wherein the received update instruction is received from an 
20 entity that is remote from said given on of the predictive dialer systems. 

8. A method of processing call information for calls to be placed by predictive dialers 
deployed at different geographic locations within a communications network, comprising: 

receiving call information for a number to be called by one of the predictive dialers; 
25 processing the call information to determine if the number is on a Do-Not-Call 

(DNC) list, a copy of which is maintained in association with each of the predictive dialers; 

if the number is determined not to be on the DNC list, determining if the number is to 
be added to the DNC list; and 
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enabling an update of the DNC list copy associated each of the predictive dialers with 
information that includes the number so that each of the predictive dialers has access to the 
information in near real-time. 

5 9. An article for processing call information for calls to be placed by predictive 

dialers deployed at different geographic locations within a communications network 
comprising: 

a storage medium having stored thereon instructions that when executed by a machine 
result in the following: 

10 receiving call information for a number to be called by one of the predictive dialers; 

processing the call information to determine if the number is on a Do-Not-Call 
(DNC) list, a copy of which is maintained in association with each of the predictive dialers; 

if the number is determined not to be on the DNC list, determining if the number is to 
be added to the DNC list; and 
15 enabling an update of the DNC list copy associated each of the predictive dialers with 

information that includes the number so that each of the predictive dialers has access to the 
information in near real-time. 

10. An apparatus for processing call information for calls to be placed by predictive 
20 dialers deployed at different geographic locations in a communications network, comprising: 
a first module to process call information for a number to be called by one of the 
predictive dialers to determine if the number is on a Do-Not-Call (DNC) list, a copy of which 
is maintained in association with each of the predictive dialers; and 

a second module, responsive to the first interface, to enable an update of the DNC list 
25 * copy associated each of the predictive dialers with information that includes the number so 
that each of the predictive dialers has access to the information in near real-time. 
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